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About the author and IT Leaders 

David McKean is a former CIO, having worked for several multi-national companies around the world, 
including AT&T ventures in Asia, UPC Nederland in Holland and Cable &Wireless in the UK. He is 
now the managing director of IT Leaders Ltd, a leading provider of IT management training. He has 
worked alongside some of the top IT leaders in the business and shared experiences with countless IT 
managers and CIO's from around the world. 

IT Leaders runs public and in-house courses, as well as providing distance learning and blended 
programmes. Public courses are run regularly in the UK and internationally, and are accredited by the 
Institute of Leadership and Management. Delegates include IT managers from all companies world- 
wide of every size and industry. Our clients include Accenture, Allen & Overy, Alstom, Amey, Barclays, 
Boeing, BT, Capita, Debenhams, DHL, HP, HSBC, John Laing, Philips, Rothschild, Royal Bank of Canada 
and Siemens. 

The IT Leaders programme looks at 8 key IT leadership skills, including organizational politics for IT 
managers, leading IT teams, business and IT strategy, technology innovation, crisis leadership, business 
change leadership, senior level influencing and corporate leadership. The IT business management 
programme topics include IT to business alignment, business relationship management, communications 
skills for IT managers, operational excellence and managing IT teams. The IT commercial management 
programme is run jointly with Mayer Brown, a leading provider of legal services in IT sourcing market. 
Topics include IT sourcing frameworks, creating a sourcing strategy, key contractual considerations for 
IT managers, service level agreements, negotiation strategy, negotiation skills, vendor assessment and 
finance for IT managers. The blended and distance learning programmes are available world-wide and 
are based on the 10 management skills model developed by IT Leaders. Courses are live and interactive, 
using on-line seminars, e-learning and assignments backed by a comprehensive course guide and 
mentoring from the course leader. 

IT Leaders also runs a vibrant network of IT Managers, available to former delegates and all other IT 
managers for a small annual subscription. The network group is vendor independent and meets three 
times a year. There is also a Linkedln IT Leaders network which is open to IT managers from all disciplines. 
The best way to join is to connect to the author David McKean and request an invitation to the network. 

I would like to express my particular thanks to the expertise of key contributors - Iain Begg for guidelines 
for successful project delivery (www.imb-consulting.co.uk), Keith Baxter of DeRisk on risk management 
(kbaxter@de-risk.com) and VersionOne for their summary of agile methods (www.versionone.com). I 
would also like to thank Mark, Wes, John, Peter and Stephen for their case stories. 
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You can also purchase David McKeans printed book IT Management: Managing People 1 on Amazon. 



Download free eBooks at bookboon.com 



IT Management: 

Projects, programs and business change 



An introduction to IT projects, programmes & change 



1 An introduction to IT projects, 
programmes & change 

This book is the third of four in our IT management series. It covers the management of IT projects, 
programmes and business change leadership. Other books in the series cover IT management skills 
for managing people (book 1), IT strategy & innovation (book 2) and IT business, operational and 
commercial excellence (book 4). The outline of the books in the series is shown in table 1 below. 



Book 1 - Managing people 

Managing yourself 

Managing IT teams 

Business relationship management 

Working with senior execs 


Book 2 - IT strategy and technology innovation 

Business strategy 

IT strategy 

Technology innovation 

Communicating and governance of IT strategy 


Book 3 - Managing IT projects & leading change 

Project & programme management 

Project portfolio management 

Guidelines for project & programme excellence 

Risk management 

The role of IT managers in leading business change 


Book 4 - Business management & operational performance 

IT to business alignment 
A model for IT governance 
Models for operational excellence 
Crisis management & leadership 
Technology sourcing & negotiation 
Finance for IT managers 



Table 1 



In putting together this series of books, I asked IT managers what they want to know to do their job 
better? This book presents guidelines and best practice from our own experience, feedback from course 
delegates and clients, guidelines from our on-line IT managers network and interviews with CIO s and 
other senior technology leaders. 

To be clear from the outset, let us define what is meant by projects, programmes, portfolio management 
and change leadership and which areas we are planning to cover: 

Project management - A project tends to be linear and temporary, addressing the implementation of one 
new component and therefore. Because this book is aimed at more senior managers, it offers guidelines for 
those managers who might be looking after a team of project managers. We also look at project portfolio 
management, the art of managing progress on a series of projects run by several project managers 
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Programme management - In contrast, programme management tends to be the implementation of 
a larger change, usually requiring the co-ordination of several related sub-projects to deliver a final 
result. Senior managers may well be running one programme and overseeing the delivery of smaller 
sub-projects into an integrated whole. We look at some of the important techniques for managing these 
larger scale programmes. 

The following diagram shows the relation between projects, programmes, portfolio management and 
business as usual (BAU). 
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Business change leadership - This is the art of ensuring that a large project or programme is fully 
accepted and adopted by the organization. It is concerned with the people side of implementing a (usually 
major) business programme. It recognizes that such business programmes may substantially change the 
way that individual employees do their work and that this can cause significant anxiety and resistance. 

This book is intended to act as a guide for managers who are involved in any or all of the above activities. 
Since most IT managers have experience in running projects, this books presents insights experience and 
guidelines to make your projects, programmes and change initiatives more successful. Nonetheless, if this 
is a new area for you, chapter 7 gives some background on two of the best known project frameworks. 
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2 Project success guidelines 1 - 
Get off to a good start 

Our first set of guidelines focus on the selection of projects themselves and setting a strong foundation 
for successful project delivery. 

2.1 Choose good projects (be careful what you ask for) 

Most business cases that go before the project review committee seem to be really great ideas at the time, 
only to lose their shine after only a few weeks. And yet, most of the reasons that projects go off the rails 
are entirely predictable at the beginning of the project. 

All the more reason to make sure that the project approval decisions are correct. If you are fortunate to 
be part of the project review process, you should be asking some very tough questions at the outset - and 
not in a few weeks time when things aren't going so well. In summary, you should be asking questions 
in four key areas (see section 3.8 on project portfolio management for more detail), in particular: 

1. Strategic priorities - if you think that your organization is going to review or change its 
strategic priorities and that this in turn will materially affect the need for this project, the 
best advice is to put it on hold 

2. The business case - experience tells us that this is the area where most projects are wrongly 
assessed. Make sure you are really clear on the benefits, remembering that some benefits 
(e.g. direct cost savings) are more easily attainable and more valuable than others (e.g. 
revenue projections) 

3. The ease of project delivery - the resources for the project should be properly sized, taking 
into account the experience of the project team and allowing for a project contingency 
(either an allowance in delaying the delivery date, or budget over-run). Additional care 
should be taken at project approval time, if adding such a contingency severely reduces the 
value of the project. This might be the case for a product launch that must be done in time 
for a critical date such as a major bank holiday. In addition, the project must meet the needs 
of the customers, and be supported by the business employees, users and stakeholders alike 

4. Endurability - ask questions around how long the project will deliver value. In particular, 
ask if there are new technologies on the horizon that could deliver more value for a fraction 
of the cost 
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2.2 Choose the right time to start 

IT's role in a business project or programme is to deliver functionality for business users. And hence 
the business users must be ready for it. Whilst IT managers should be on the lookout for warning signs 
- key sponsors not turning up to project meetings or users not attending training sessions, for example. 
Speak to key users and sponsors to understand their attitude to the change. They should be seeing the 
change as highly positive, an opportunity rather than a burden or a threat. If there are any concerns 
in this regard, raise it at the Project Board and consider postponing the project until the time is right. 

Dieter's story 
Background 

I was working for a telecommunications operator in Germany. It had been known to some time that this operating 
unit was having problems. It frequently appeared on the national news amid stories of poor network quality and very 
low customer satisfaction. A new management team was brought in to turn things round. 

What happened 

The management team was led by a very charismatic figure, an ex-special services officer. Every Wednesday 
afternoon, the management team of eight senior managers met to discuss progress. The meetings were tough, but 
the chief executive led things forward through a mix of determination and a raw sense of humour. 

One afternoon, however, the mood was very different. It transpired that a gunman had gone into one of our sales 
outlets and put his gun to the head of one of the employees. At first we assumed that this was a crazed drug addict. 
A sales outlet seemed an odd place to choose, though, as we didn't have much cash on the premises. It turned out 
that this person was in fact one of our customers. He had become so incensed with the level of service we provided 
that he had been trying for six months to end his contract. 

The company was so incompetent that it was unable to carry out this simple task, continuing to send bills and 
threatening letters for a service that the customer hadn't asked for and didn't want. So frustrated and angry had he 
become, that the only way he could think of to get the undivided attention of our organisation was to hold us up at 
gunpoint. 

Lessons learnt 

I remember being very shocked at the time, but it did give us a very real sense of what we were doing to our 
customers. And in turn, it did galvanize us to achieve an extraordinary turn around in the following 1 8 months. 
Sometimes it takes an outside event to really make you see things as they really are. 

2.3 Choose a good team 

Few project managers themselves get to choose the people who are going to work with them. Fortunately, 
it can be solved by good IT management. If you are in charge of a number of project managers, an 
important part of your job is to make sure that the team on each and every project has a balance of 
skills and experience. 



Download free eBooks at bookboon.com 

12 



IT Management: 

Projects, programs and business change 



Project success guidelines 1 - Get off to a good start 



Book One in this IT Management series outlines the 9 key roles that a successful team should have, 
following the research of by Dr Meredith Belbin. 1 Belbin assessments can look at the overall structure 
of project teams, identifying their strengths and weaknesses. 

Be on the look-out for "part-timers," those people that have other responsibilities besides the project 
itself. For multi-functional projects, such as a company-wide ERP or business intelligence system, the 
project will need representation from a number of different departments. It is vital then, that the key 
project members are committed to the project - and that probably means working full time on it. Part 
timers can be disruptive, turning up as spectators to meetings and too easily able to feign ignorance 
about issues they should have been responsible for. On the other hand, not unreasonably, "full timers" 
might feel vulnerable at the end of a project, particularly if it is a long one. Organizations need to make 
sure that successful project members are not rewarded by losing their jobs. 



1 More information on the Belbin roles and project team assessments can be found on their website, www. 
belbin.com 
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Mark's story 
Background 

At a 6000 staff global enterprise based in London, a strategic business decision was made to relocate 50% of IT and 
business services roles to a new office in Ireland. The ultimate goal was to reduce the costs of the support services. 
Many of the IT roles to be relocated were highly experienced operational staff who were typically working in a highly 
customised environment. Key to the successful transition of support services was a knowledge transfer to new staff 
prior to redundancies taking place. The business cost savings were based on a handover of just 3 months. 

What happened? 

Once the business decision was public, it was determined, that the depth of knowledge for transfer would require a 
significant number of staff needed to be dedicated to this knowledge transfer. This meant that all current teams were 
down on headcount and hence services were impacted. 

Non-essential work was moved down the priority list (to free up staff for training and knowledge transfer) - to do 
this, governance and resource management was introduced through the transition period to minimise the impact to 
services. Most new work requests were pushed back, creating a backlog of existing maintenance, all of which would 
still require resourcing at a later date. 

It turned out that 3 months was not sufficient. A number of redundancies had to be deferred to extend the transition 
period. This was the result of the incumbent knowledge not simply being of a technical nature, but also based on 
many years of experience of the systems. 

Lessons 

Always fully understand upfront the resource requirements to implement such business change. 

Understand the impact on services and costs that such requirements will have. 

Don't underestimate the importance of staff experience. It is not simply a case of recruitment and 

training. 

Involve trusted IT staff with the deep knowledge to contribute to these calculations. 

Consider the longer term impact of additional pressures on staff, and the implications of low morale. 

Ensure the resulting risks to services are signed off by the business. 

Communications to the end users are essential, so that their expectations are managed. 

2.4 Be clear on what is being delivered 

Projects need to be performed and delivered under certain constraints. Often, when a project is first 
conceived, it is required "betterfastercheaper!" Of course, not every project can be delivered immediately 
for no cost and meet all the quality criteria. These factors are mutually exclusive. The general view is 
that you can have two of the three, i.e.: 

1. Quickly and to a good standard, but it will be expensive 

2. Quickly and cheap, but it will not be very good quality 

3. High quality and cheap, but it will take a long time 

This can be shown in the triangle below A stakeholder will need to choose where on the triangle the 
project should fit. 
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Figure 1 



The time constraint refers to the amount of time available to complete a project. The cost constraint 
refers to the budgeted amount available for the project. The scope constraint refers to what must be done 
to produce the project's end result. These three constraints are often competing constraints: increased 
scope typically means increased time and increased cost, a tight time constraint could mean increased 
costs and reduced scope, and a tight budget could mean increased time and reduced scope. 

The discipline of project management is about providing the tools and techniques that enable the project 
team (not just the project manager) to organize their work to meet these constraints. 

2.5 Create a high level architecture 

Once the business case is approved, the information systems department needs to get down to its work. 
Before the project gets too far down the track, there should be a proper technical design. IT project members 
need to get together and agree what is required and in particular which systems and process changes are 
needed. From the requirements, the team should be able to put together a high level architecture that 
describes what the future technical configuration should look like. The aim of this is three-fold. 

• First of all, staying at the high level provides a useful mechanism for the architects to 
identify the best technical solution. Assuming that everyone stays at the high level (and 
this is a big assumption), it allows the group to think of alternative high level solutions. The 
benefit here, is that solutioning at the high level, before moving to the detail, means that the 
detail only needs to be done once 
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• Secondly, drawing up a high level architecture provides the project team with a view as to 
how much work is required 

• Finally, it acts as a description of the project "vision." Although vision is normally associated 
with the business improvement that a project will deliver, a high level technical picture can 
also help the project team to visualize the end point. 

Michel's story 

A utilities company was looking to migrate its customer order platform to incorporate additional new services. 
The technical architects had a very difficult job to do and the block diagrams were very complex. For each block 
at the high level, there was a detailed technical specification. Before all the technical specs were finished, the 
team enhanced the overview block diagram, making it understandable by the rest of the team. This meant that all 
architects had to agree on this diagram. 

This overview schematic shaped the architecture from a strategic point right at the outset. In turn, this meant that the 
detail only had to be done once. The diagram was 'coloured in' as one of the architects put it, and was suitable to be 
communicated to the business stakeholders and users. This turned out to be more important than was first imagined. 
First of all, it was important to the project team that they could understand what the technologists were trying to 
produce. Secondly, it helped them to understand that this was not a simple task and required their full attention. 
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3 Project success guidelines 2 - 
Managing project progress 

This book is concerned with managing projects at the higher level, so we focus on techniques for 
programme managers and project portfolio managers. 

3.1 Develop strong project management skills 

If you are running a project team, the importance of having standards and methods around managing the 
different projects will be no surprise to you. It only takes a few days of trying to consolidate reports in 
different formats to realize the value of good, consistent reports that can be aggregated to give an overall 
view. This applies equally whether you are a programme manager bringing together the sub-projects 
together into an integrated picture, or a project portfolio manager required to manage diverse projects. 

Chapter 7 gives some guidelines of two leading project methodologies - PRINCE 2 and PMI's project 
processes. The thoughts in this chapter assume you have a good project methodology in place and are 
constantly striving to get the most out of it. 

Firstly, project managers must be trained in the project method used by your organization. When we 
poll senior managers, the vast majority are using some project methodology in their organizations. 
Interestingly, almost all of these organizations have adapted a standard framework to suit. If you have 
modified PRINCE2 for example, and you recruit a qualified PRINCE2 project manager, you may still 
need to give them a grounding in your particular methods, the report formats, frequency, how you 
manage risks and so on. 

Secondly, recognize that fully qualified project managers are no guarantee of successful project delivery. 
Project management is analogous to driving a car. Just because you have a driving license, does not 
make you a good driver. It takes experience as well. Below, figure 2 shows our model of the key 
management skills for managing projects. These skills are represented in different forms in the different 
project methodologies and many of the key disciplines of project management require advanced people 
management and analytical skills. As the leader of a project team, you will have a permanent responsibility 
for identifying problems and developing the skills of your team. 
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Figure 2 



There is so much for a project manager to learn about project management techniques, that it is difficult 
to know where to start. The following table has been put together by senior managers who have attended 
our leadership courses as a guide for what project managers should focus on. 

Guidelines for your project managers 

Make a good plan - A good plan that everyone understands and agrees with, is probably the most important advice. 
The plan must address the real priorities of what you are trying to achieve and have the necessary resources. There 
should be enough planning detail for it to be clear what is to be done, but not so much, that the planning needs to 
be re-cast every week. Don't assume that more tasks is better. Anyone can use the copy function in Microsoft Project! 

Stay informed - keep all of your communication routes open and keep listening to the advice of others. In particular, 
your champions will give you frequent feedback from the field as to how things are going, current issues faced and 
potential problems in the future. Actively seek the advice of others and adjust your plans accordingly. Keep everyone 
updated of progress and milestones that have been achieved. 

Stay flexible - There is a helpful phrase used as a watchword in the military, "Indecision is the key to flexibility." It 
means don't rush to make decisions that don't need to. A good example is procurement approvals. Your vendors 
will want you to buy early and in large quantity. Resist this pressure and buy only what you need when you need it. 
Staying flexible may mean changing targets or reviewing project deadlines. 

Keep to time - Don't delay deadlines unless you have to. It sends out the wrong message and people will use it as 
an easy way out of project difficulties. I remember interviewing a promising project manager who said he always 
delivered his projects on time. In reality, it turned out that he kept all his project plans on his computer and restricted 
access to them. And, anytime things looked like they might slip, he just moved the end dates out. Simple! 

Focus on benefits - keep focused on what you are trying to achieve. Don't get distracted trying to achieve too many 
things at once. It is like carrying suitcases. It is easy to carry one or two at once. As soon as you try to carry four or five at 
once, it becomes impossible. Keep checking that the results are the right ones. When results have been achieved, make 
sure that they are recognized with senior management and that the team is properly congratulated and rewarded. 
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Look after your team - all the time, and be on the look-out for how everyone is performing. Keep them all 
motivated, busy and working together. Set up regular opportunities to share information, and keep celebrating 
success. Where possible, be on the look-out for good people who may want to join the project. Good teams attract 
good people and good people make good teams. 

Don't do everything yourself - To use a musical analogy, it is not possible for one person to play a symphony, 
however talented they are. Substantial projects need the combined efforts of many players. In any business 
project, many team members with different skills are needed to create the finished product. Your role, is that of the 
conductor, recognizing and empathizing with what everyone needs to do. Doing the work of your team members 
(even if you think you are good at it) is highly counter-productive. 

Handle conflicts early- As the metaphorical conductor, your job is to ensure that everything works in harmony. As the 
project progresses and the pressure increases, these problems are increasingly likely to appear. Be on a constant look- 
out for problems and catch them as early as possible. If there are personal disputes, speak to both parties individually 
before you bring them together. Telling people to 'pull their socks up' or 'just stop it', is an ineffective management 
approach in today's business world. It is important to identify whether a dispute has arisen out of personal differences 
or project differences. Seek to understand the basis of the real problem and take steps to resolve the root cause. 



Table 2 



3.2 



Make them sweat the small stuff 



Project managers are paid to sweat the small stuff. Their project plan needs to contain all the necessary 
tasks so there are no surprises along the way. Project managers should know where the critical path is 
and what the key dependencies are. 






It's only an 
opportunity if 

you act on it 




IKEA.SE/STUDENT 



«siE 







Download free eBooks at bookboon.com 



19 



Click on the ad to read more 



IT Management: 

Projects, programs and business change Project success guidelines 2 - Managing project progress 

The most common way to present a list of tasks is the Gantt chart (as opposed to a network diagram 
or what used to be known as a PERT chart). The Gantt chart has the advantage of listing all the tasks. 
The duration of the task can be easily seen by the length of the task bar it represents on the Gantt chart. 

Gantt charts are not so good at showing dependencies as often the dependency lines merge and overlap. 
In this case, it helps to show the network format too. The disadvantage of the network format is that it is 
time consuming to create. It is certainly the recommended format, though, for high level project plans. 



Why projects fail - Don't lose your RAG + 

A key principle of successful project management is KISS (Keep It Simple and Straight-forward). And in a simple 
world, using RAG (Red, Amber, Green) reporting, Amber or Red status means"! need help." 



Sphere of Influence 

The project manager's immediate sphere of influence includes those things that they themselves can fix. A project 
manager reporting their status to the Project Board, should only be using the Amber or Red status for issues that are 
outside this sphere of influence. Project managers should always have risks and issues to address, but that does not 
mean the project should be amber or red. 



Red vs. Amber 

Some managers don't like projects that suddenly appear as red and think they should first go to amber. Don't be 
fooled. If your project needs urgent help, the sooner you flag it the better. 



Crying Wolf 

Project managers should not use amber and red to panic the Project Board into allocating more resources. Amber 
and red status should only be for risks and issues outside the project manager's sphere of influence that may affect a 
successful project outcome. 



Don't get angry! 

In his book, How NASA builds teams, Charles Pellerin ++ writes that one of the major failings of the Hubble telescope 
mission was the behaviour of NASA towards its contractors. As one contractor was quoted, "Eventually we were so 
tired of the beatings, we stopped reporting problems." A sign of a good Project Board is where problems can be easily 
raised and discussed without them falling into an argument of blame and retribution. 



t 'Don't lose your RAG,' Iain Begg, 1MB Consulting. Full paper available at www.imb-consulting.co.uk 
tt How NASA builds teams, Charles Pellerin 

Table 2 

When it comes to detail, work breakdown structures may also help. The work breakdown structure 
(WBS) is a tree structure that shows a subdivision of effort required to achieve an objective— for example 
a program, project, and contract. The WBS may be hardware-, product-, service-, or process -oriented 2 . 

A WBS can be developed by starting with the end objective and successively subdividing it into manageable 
components in terms of size, duration, and responsibility (e.g., systems, subsystems, components, tasks, 
subtasks, and work packages), which include all steps necessary to achieve the objective. 



2 For more information on Work Breakdown Structures, see the Project Management Book of Knowledge 
(PMBOK), published by the PMI 
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The work breakdown structure provides a common framework for the natural development of the 
overall planning and control of a project or program and is the basis for dividing work into definable 
increments from which the statement of work can be developed and technical, schedule, cost, and labour 
hour reporting can be established. 

3.3 Keep a high level overview for yourself 

Rule number one - project reports must be useful and to the point. If you are running a team of project 
managers, you will be delighted that they are taking care of the detail. Even though the project managers 
deal with a lot of information, don't let them put the "monkey on your back 3 " by involving you in their 
detail. 

To avoid micromanaging, it is all the more important that they provide the right information to assess 
progress. Have a standard format for project status reports. If you find yourself reading a lot of irrelevant 
(i.e. not interesting) information, then revise the format. Keep in mind that one size may not fit all. More 
complex projects require different reporting structures. 

Stephen's story (part 1) - implementing a mobile phone network 

Where a detailed project plan is important for smaller projects, a high level view is essential for larger programmes. 
Some years ago, I worked for a major telecommunications company that was building a mobile network in France, 
there were about 50 major projects within the overall programme. Each project plan had hundreds of project tasks. It 
was even more important then, to see how the overall programme was developing without getting sucked into the 
detail. 

We created a high level view using a network diagram format printed on A1 with about 200 key milestones. It was 
easy to visualize how the programme would pan out - a bit like looking at a time lapse type view of the future. Each 
milestone probably represented about £2m of capital spend on average. It proved a vital tool to see how progress 
was being made and how the major projects within the overall programme were interacting. 

When it comes to reviewing project reports, take a look at the risk register that is presented. Good 
project managers should be able to identify and report just the top 5 to 8 risks from the full risk register. 
Conversely, a project that is not being managed well can often be spotted by the fact that the project 
manager either reports all the risks, suggesting that they have no understanding of the relative importance 
of each one, or none at all. 

3.4 Tips for managing costs, contracts and suppliers 

Project managers need to keep a tight rein on budgets. This usually means keeping a tight rein on suppliers, 
be they contractors or technology specialists, systems integrators, equipment suppliers or developers. 



3 Who's got the monkey, Onckon and Wass, Harvard Business Review reprint 99609 
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One of the key lessons from our research and delegate feedback is to get the timing of purchasing right. 
It is better to approve purchases for delivery slightly ahead of when they are needed, and avoid buying 
in large quantities until absolutely necessary Set up project costs codes for each project and manage 
supplier approvals carefully Strike a good balance between putting the right checks in place to keep 
costs under control and slowing down project progress. 

Give yourself as much time as possible when signing up vendor services to agree contract terms. Include 
clauses that protect you from vendor problems with implementation and subsequent support. If a vendor 
senses that time is not on your side, they may use it to their advantage, persuading you to take on services 
before the contracts are fully signed. Whilst there may be times when this is the only course of action, 
the recommendation is to start work on contracts at the earliest opportunity, make sure there is a team 
dedicated to the task, and keep competitive tension in the deal as long as possible. 
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Wes's story - telephony & contact centre system 
Background 

The organisation that I work for has 3 sites with call centres at two of them handling almost 1 million calls per annum. 
Both had different telephone systems that were old and expensive to support. My department was tasked with 
identifying what benefits might be available from a replacement phone and contact system, building a business case, 
selecting a supplier and then managing the subsequent implementation. 

What happened 

The project was kicked off and all project team staff signed up to a project charter that had commitments around 
project governance and communication. This worked extremely well as all staff knew what was expected of them. 
We also utilised a web based project management and collaboration system for the first time. This enabled the 
project team, including external staff, to monitor the progress of all tasks as well as collaborate and share information. 
This created a more productive, well informed project team. It also enabled me as project manager to have up to 
date information on all project tasks at all times which needless to say aided decision making and resulted in less 
'surprises'. 

The project sponsorship was strong, supportive and trusting, expecting that any issues would be reported as and 
when they occurred. This, together with close project management, enabled the project to be delivered on time, on 
budget and within a tight timescale. 

Lessons learnt 

Whilst the project was a success, we learnt a number of lessons both good and bad from this project. It was certainly 
a positive to set up a project charter as everyone knew what was expected of them and made them more productive 
project team members. The use of a web based project management system worked extremely well for the staff 
in my organisation. However, it was not available to the delivery partner prior to placing the order and it was less 
efficient at managing their tasks. This was also one of the first projects where we introduced a robust benefits 
realization tracking process. So far, I'm pleased to say, they are currently on track. 

High quality suppliers can often help enormously with expertise, insights and guidance on what is 
working and what isn't. Resist the temptation to confine them to the basement. Like any high quality 
professional, they will work much better with a good working environment. Provide them with access 
to office facilities where they need it, but at the same time, don't feel obliged to set aside free office space 
if they are not working full time on the project. 

3.5 Set up good project governance 

Project governance does not have to be difficult. In IT organizations, project governance usually works 
at three levels. First, there is the project review meeting. This is the (typically weekly) review of project 
progress with the main project members and stakeholders. Depending on the size of the project (and 
particularly with programmes), there may be sub-meetings that feed their findings into the project 
review meeting. Secondly, there is the IT project review meeting. This is normally run by the IT director 
or head of IT projects. This meeting checks that the IT project teams are fulfilling their obligations in 
the delivery of project. The chairman can then take the findings from this meeting into the higher level 
project governance board. 
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The project governance board is where all company projects are reviewed. These meetings review the 
progress of capital investment decisions. They are therefore extremely important and yet, a surprising 
number of organizations do not have formal governance at this level. If your organization is one of 
these, you may wish to consider working with your senior management to set it up. The importance of 
this (organization-wide) high level project review is discussed in book four in this series in the section 
on governance. 

Project review meetings are important for many reasons - obviously they read out the progress of the 
project and highlight issues that may need management decisions. But they also showcase the ability of 
the project teams and in particular, the project manager. Since the meetings are important, the project 
team leader should spend time with their project managers ahead of time to prepare them and make 
sure they keep to the point. 



Avoiding Project Sponsorship becoming a spectator sport - our top 3 tips 1 

Projects don't fail in the end, they fail in the beginning. Project governance is the most common reason projects fail. 
The following three tips will help you to set your project up for success (for more on project sponsorship, go to www. 
imb-consulting.co.uk) 



1. Goal setting 

If you were to ask the Project Manager and Project Sponsor, "What are the goals of this project?" nine times out of 
ten, you will get a different answer. The reason could be a lack of communication, different assumptions or the fact 
that time has moved on, and the priorities have changed. Together, the project sponsor and project manager should 
put together a Mission Statement that encapsulates the project's goals and success criteria. Review this periodically 
as the project progresses. 



2. Give airtime to the project manager 

The responsibility of the project sponsor includes articulating the high level scope (i.e. goals and success factors), 
approving the proposed solution, securing financial and human resources, making prioritization decisions and 
exerting their power to facilitate the resolution of issues and risks. An experienced and hard-nosed project manager 
would be expected to provide delivery focused plans, identify issues and potential solutions, mitigate risks and 
prioritize to meet deadlines. Without the two speaking regularly to each other, the Project Sponsor and Project 
Manager are likely to make assumptions which may constitute significant risk to the successful delivery of the project. 



3. Getting the governance right 

A project will consist of (in descending order of importance) - the business sponsor, the project steering group or 
project board, stakeholders, affected parties and interested parties. It is important to identify which category project 
members fall into to get the best results for your project. Some stakeholders are incentivised to see a project succeed 
and will move heaven and earth to make it so. But not all stakeholders can commit to attend steering committee 
meetings, so a small (highly motivated) subset should be elected as the decision makers to form the Project Board. 



t 'Avoiding Project Sponsorship becoming a spectator sport' Iain Begg, 1MB Consulting. Full paper available 
at www.imb-consulting.co.uk 
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Project review meetings should be less about project progress and more about making key decisions. If 
something has gone wrong, the project team leader should work with the project manager prior to the 
meeting to discuss the strategy. Similarly if a particularly difficult stakeholder is expected at the meeting, 
the project manager should meet them ahead of time (with their team leader if necessary), so that any 
disagreement doesn't hold the meeting hostage. Project managers should choose their attendees carefully 
so meetings don't become too big and unmanageable. 

3.6 Communicate clearly to all parties 

Good communication between management and employees is vital in all successful change programmes. 
Communication needs to be open, working across different levels of seniority and regardless of position, 
offering an openness in discussing programme issues. There needs to be a free flow of information, 
ensuring that team members have access to what they need to know in order to achieve their objectives. 
There should be regular formal communication as well as the smart use of informal channels. 

John's story - the need for buy-in 
Background 

Every project manager talks about the need for communication and buy-in. Of course this means different things to 
different people. A client of ours told me a story of a large project that they were working on. It required a massive 
upgrade of the technology platform to enable the launch of a range of new services. 

What happened 

It was so urgent that the former technology officer had awarded the project management contract to a company that 
had recently worked on a successful product launch. But the project was starting to stall. It soon became clear that 
the project management company was unqualified to deal with such a complex technical launch. The project was 
estimated to take nine months, and three months into the project, the completion date was still nine months away. 

An old saying came to mind when I was being told this story. "We never have enough time to do things properly but 
often find the time to do things twice." And so it was in this case. Soon the project management contract had been 
re-awarded to a major international systems integrator and we started again from scratch. 

The systems integrator put in their elite programme management team and technology experts. Within a matter of 
days, it was evident that things were starting to move forward, even though the project was effectively still three 
months behind schedule. It was now March, and the original date for product launch was September. To be honest, 
most people in the company were expecting completion towards the end of the year. 

The new project team worked closely with the key business sponsors and in July, just five months later, the projected 
launch date was predicted to be somewhere towards the end of September. The new CIO was speaking to the head 
of customer operations discussing what he thought was good news. 

The head of customer operations said that while she was impressed with the progress that the IT department had 
made on the project, she was getting some resistance from the sales force. That morning, she had received a petition 
with 1 00 signatories, asking for the launch date to be delayed. 

The CIO was furious. He could not understand why the sales force whose only obligation was to attend a four-hour 
training course would not be ready when his team had spent 1 6 hours a day in the last six months trying to get 
things finished. 

Lessons learnt 

The lesson learnt was basically that even though the programme managers, the IT department and the key business 
sponsors were all fully aware of the stellar progress of the project, no one had bothered to tell the sales people that 
things were back on track. Their minds were still expecting a launch date towards the end of the year. 



Download free eBooks at bookboon.com 

25 



IT Management: 

Projects, programs and business change Project success guidelines 2 - Managing project progress 

As the case study above describes, communication is not just talking to those people who will be turning 
up anyhow to the status meetings. It is about telling everyone who will be affected and making sure they 
are prepared well in advance for the change. Stakeholders exist throughout the organization. Apart from 
the project team itself, they include: 

1. Key business specialists 

2. Senior management and sponsors 

3. All the managers whose departments are affected by the change (including IT departments 
such as IT operations) 

4. All users who will have to adopt the new systems 

A plan should be in place for how the project will communicate to each of these stakeholder groups in 
turn. Remember that the same method of communication will not work for the different groups. If you 
are providing training programmes, monitor the course quality and put critical tests in place to verify 
that the training has been completed and is fully understood. 

3.7 Keep measuring value (SPRINT) 

One of the dangers of project management is that delivering the project plan successfully does not always 
translate into a successful project. Market conditions may change for example between a project starting 
and a project completing. It is worthwhile to keep monitoring the value your project delivers and to this 
end it is helpful to have a checklist to help - the one we recommend is called SPRINT which stands for 
Situation, Problem (or opportunity), Risks, Impact, Needs and Timing . The SPRINT tool suggests that 
you make a simple one-line statement on each of the 6 items and regularly review them. 

1. Situation - this is the business driver that caused your project to be set up in the first place. 
The Situation is similar to the business context and describes the market opportunity in the 
case of a business project. 

2. Problem (or opportunity) - What is the problem that the business is facing, or what 
opportunities is it looking to exploit? Create a statement that summarizes the specific 
problem that the project is seeking to address. 

3. Risks - What are the risks of not doing the project and what are the downsides of doing 
the project and what are the significant things that may go wrong. This is not intended as a 
detailed risk assessment at this time? 

4. Impact - What is the benefit that is expected from the project? It is important to keep 
reviewing this. 

5. Need - What are the key features that are needed by the project to ensure that the value is 
delivered and are they being delivered? 
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6. Timing - How quickly does the project need to be completed based on assessments of the 
market competition? It is clear therefore that if competitive offerings are launched that 
impact on the value of the project, the project may need to be delivered faster. Similarly if 
the market demand fades, it might be worth putting a project on hold 

We have come across many companies with ambitious projects and change programmes. Some of them 
are successful and others less so. One of the biggest problems with the less successful organizations is that 
they confuse unrealistic targets with ambition. All companies strive to stay ahead of their competition. 
But any change programme has to be realistic and in our opinion one of the best ways to achieve this 
is to deliver value in stages. 

In our project management courses, we talk about the importance of stepping stones. These are almost 
like points of safety along the route of the project plan. It saves the project manager having to deliver 
everything at once, analogous to making one enormous leap from one river bank to the other. The 
stepping stone approach means that you break the project down into sequential phases. The project can 
then be appraised at various points along the path and change course if required. 

One of the options might be to change the project deliverables and one might be to delay the project. 
The most common reasons for project delay is a scarcity of resources particularly on the end user side. 
But there may be other reasons such as changing economic conditions or re-prioritisation of projects. 
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Stephen's story (2) - Keep delivering value 

Background 

When a French mobile telephone provider won its licence to build a GSM network in France, it embarked on a long 
project to build the central switches, radio subsystems and transmission. Notwithstanding the fact that the licence 
bid itself took over six months, building a competitive network requires huge skill and dedication over many months. 

There was a danger that the organization would lose energy. Huge amounts of work had been done, but it sometimes 
seemed difficult to keep the end goal in sight. It was for this reason that when the central infrastructure was in place 
including the main switches and primary radio network, the company chose as its next project to get the offices 
connected and working. 

This meant that employees of the fledgling mobile operator could see for the first time what they were trying to 
create. They were able to make phone calls using new handsets on their own network. 

Lessons learnt 

It would still be several months before the secondary radio network was in place and the company was ready to 
launch. But this first victory was a very valuable step in the company's history. The management team was reminded 
of the importance of delivering small successes along the path. 

3.8 The art of managing project portfolios 

Any manager in charge of other project managers needs to be able to review all of the projects in their 
responsibility. This process of managing and reviewing a collection of projects is called project portfolio 
management. Indeed, in large global organisations there are generally multiple Portfolios e.g. Functional 
Portfolios and Regional Portfolios which will often compete for resources and for priority. 

If you are on a project review team, you may have encountered a number of frustrations, which would 
be very typical of this type of meeting. Project review meetings can often be drawn out, with project 
managers talking at length about the projects they are close to. To preserve everyone's sanity, it is important 
to maintain some discipline. Project managers should get into the habit of summarizing their projects 
and project status in 2 minutes. This prevents them from "winging it" and using the project review 
meeting as their time to prepare! 

Effective governance of a project portfolio also means dealing a firm hand in reviewing priorities. All too 
often organizations approve projects in one business context and fail to review them when the context 
changes. There are many things that can change the context. 

1. The economic market conditions 

2. The business case and the business priorities 

3. The cost or timescale of the project 

4. The impact of other projects 
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On the final point, there is sometimes a view that if a project has been approved, it must be done as 
soon as possible and at all costs. This is a false assumption. Every project takes up resource - resources 
that are not then available to other projects. Just because a project under way has a good business case, 
does not mean there aren't better ones. Effective project portfolio managers have an instinct and an 
understanding of which projects are standing in the way of more valuable ones. 

IT managers should not object when the business wishes to change priorities. On the contrary, this 
should be welcomed. It is a fact that top calibre managers are more comfortable in changing priorities, 
putting projects on hold and cancelling them than less experienced ones. 

On the other hand, it is not healthy for projects to be constantly started and stopped. What is needed is 
a rational way to evaluate projects that allows the business to focus IT project teams on their priorities. 
The best way to do this is with a project portfolio management tool. There are many on the market, but 
we offer the following four guidelines for successful IT Portfolio Management 

1. Light in weight - a key benefit of project portfolio management is that the whole business 
uses it 

2. Describes the value of the project in business not IT terms 

3. Provides sufficient detail for the business and IT to identify and mitigate risk jointly 

4. Acts as the primary vehicle to measure benefits (and Value for Money 

Even without the tool in place, it is still important to measure the relative importance of different projects. 

We have developed a 4 point guideline which we call A to E. A stands for "Alignment index" - this is 
the overall measure that we will use to measure the value of a particular project. The alignment index 
comes from the make-up of four metrics: 

B - Is this project a business priority given the current situation and strategy? 
C - Is this project cost effective providing robust benefits for a good price? 
D - Is this project deliverable given time and resource constraints? 
E - Will the value endure beyond project completion? 

The B and the C components are more important that the D and the E. Some companies therefore 
double the value of B and C to give a more accurate weighted measure. However, much of the value of 
this technique is around the discussion of projects rather than any precise value. 
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Title B C D E 


E A Score Action Comment 


1 


Project A 


10 


8 


9 


9 


90% 


Go 


Significantly increases market share 


2 


Project B 


9 


9 


4 


3 


75% 


Modify 


Good project but must reduce cost 


3 




10 


7 


8 




73% 


No Go 


Has only a short term impact 


4 




9 


9 


9 


7 


85% 


Go 


Creates significant brand awareness 


5 




9 




8 


7 


68% 


No Go 


Not acceptable to key stakeholder 


6 




4 


3 


10 


3 


50% 


No Go 


Non starter 



Table 3 



The aggregate "A score" of a project (column 7 in table 3 above) does of course change throughout its 
life time. This may be caused by: 



1. The business priority changing because the business strategy is revised 

2. The cost effectiveness (i.e. business case) changing because market forecasts change or the 
project costs increase 

3. The deliverability changing because of problems with resourcing or the supplier 

4. The useful life of the project changing (its endurability) as new technologies are announced 
the supersede the existing one 
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For this reason, therefore, projects should be continually reviewed to see if they are still well aligned 
to the business priorities. And if they aren't, it is important to act quickly Clearly it rarely makes sense 
to stop a project if it is close to completion. However, as we have observed, it is the more successful 
managers who are much more willing to stop projects that are not delivering. 

IT project portfolio meetings 

To the Head of IT Projects, the project portfolio meeting is a vital tool in managing the performance of 
project delivery in the organization, providing an opportunity for IT project managers to come together 
and share experiences. If the chairman does not exercise discipline, these meetings can be incredibly 
tedious. It helps of course to have a sharp project reporting format. The project readout too should be 
short and sharp, leaving time for the Head of IT Projects to ask some more incisive questions. In table 5, 
we list some of the questions that may help you assess true project progress and status. The sharp eyed 
reader will infer that not all project statuses are accurate. And they would be dead right! 



Questions to ask at project portfolio review time 


What can 1 do to help? 


A good question - this always puts project managers on their guard the first 
time they are asked it! (Don't ask it though, if you are not prepared to help). 


What are the biggest risks and 
how have they been derived? 


The idea of the question is twofold - first of all, it will tell you if the project 
manager has considered the risks, and secondly, do they have a view as to 
which ones they should work on? 


How good are the estimates (e.g. 
of project plans, task lengths, 
budgets etc.)? 


A tricky question, because they are estimates. Usually the project manager will 
talk about something else and, if you listen carefully, you will find out what they 
are concerned about. 


What have been the specific 
project achievements in the last 
week? 


This is quite an aggressive question, but one to ask if you think your project 
manager has either been busy on other things, or is not focused. 


Did you do what you said you 
were going to do? 


This is a telling question - it is easy to list achievements, but harder to admit that 
we didn't quite achieve what we set out to do. 


On a scale of one to ten, how 
happy are you with the project? 


This is a bit of a trick question. Good project managers will never give a project 
ten out often as they are always looking for improvements - and they also 
know that if they say everything is great, then resources may be handed out 
elsewhere. Ten out often suggests a project manager who sees the world 
through rose tinted glasses and is therefore more likely to get caught out by 
'unexpected' problems. 



Table 5 
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4 Project success guidelines 3 - 
Closing the project 

Any project team manager must be there for their team. And the time they are most needed is often as 
the project is nearing completion. It is all too easy for project managers and project teams to take their 
eye off the ball, trying to secure a role on another project that is about to kick off. But experience tells 
us, that there are many things that can go wrong on a project right at the end. 

4.1 Get ready early for the "go-live" 

As a project nears its close, attention moves towards the operational mode. Most operational managers 
will tell you that this is often too late. Certainly, experienced project organizations ensure that operational 
managers are involved in the project from the earliest stages, so that the problems of performance, 
scalability, systems management, security and so on are properly considered. 

Training courses should be completed by all users who will be using the system. User manuals, including 
quick start guidelines should be created and distributed to all users. The application support teams need 
to be fully trained on the new system (assuming there are software support implications) and there 
should be enough personnel to field calls on go-live. It may be worth considering a special "media style" 
campaign, using the intranet, company newsletter, posters, etc. to inform everyone of the changes being 
planned and the go live date. 

John's story 
Background 

A utilities company in Africa was looking to implement a major change programme. The company had grown 
quickly through acquisition and now comprised 5 separate divisions. The head office believed that the future lay 
in standardized information systems to realise the economies of scale of the acquisitions. The head office CIO 
department was proposing an integrated solution using best-in-class software applications, integrated with an 
Enterprise Architecture Integration (EAI) layer. However, unfortunately, the biggest division already had its own 
custom-developed system which it was unwilling to relinquish. 

What happened 

Fortunately, two of the divisions had already signed up, and within 4 months, the first of them had gone live 
and quickly started to realize benefits. The implementation team realized that the project had gained significant 
momentum and still did not want to give up on the biggest division. The central CIO team was also smart enough to 
realize that it could not impose a new system on anyone that was unwilling to implement it. 

Instead, the CIO spent significant time with the reluctant operating division, in particular with the main business 
directors, asking them to talk about the problems they were encountering. It soon became apparent that all was not 
well with their bespoke system. Some elements that had been developed recently were operating well, but the older 
modules were starting to become slow and cumbersome. 
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Rather than try and persuade this division to move to the new system in one go, the CIO decided to approach the 
implementation in a step by step way. The division agreed to replace their oldest module which had the biggest 
problems, with its equivalent from the new architecture. Gradually, when the operating division came to see the 
benefits of the new module, they asked for the implementation of the other modules to be accelerated. The project 
was completed within 24 months, almost the same time it would have taken if they had tried to do everything at 
once. 

Lessons learnt 

There were several lessons to take from this. The first came down to trust. The operating division did not believe 
that a so-called off-the-shelf system could provide the depth of functionality that was needed. It turned out that 
this wasn't the case. But, by not forcing the issue, the head office allowed the local operation to identify problems 
themselves and take ownership of resolving them. 

The second lesson, was about not giving up. It was important for the head office, to continue the momentum of the 
overall change project. It was not the ClO's intention to replace everything as quickly as it turned out, but rather, take 
things a step at a time. The step by step approach did give the operating unit time to adjust to the change, and once 
the project had started, there was no going back. 

4.2 Make the change "irreversible" 

Going through a major change programme is tough. The programme itself is the just the end of the 
beginning. It is vital that any new system is accepted by the users - good training helps, but users also 
have to be committed in their hearts and minds, and that is down to strong leadership from the business. 
IT managers need to coach, guide and support this wherever possible. 
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It also helps to make the change "irreversible." In other words, programme managers need to make sure 
that there is no reversion back to the old way of doing things. It is also important that organizational 
designs and performance management systems - recruitment, performance measures and rewards - are 
aligned to drive new behaviours. 

Kate's story 

Background 

Our company provides professional services to small and medium sized organizations. 

What happened 

One of the first projects I worked on was the implementation of a document management system. This would, 
we thought, have massive benefits in filing and sharing documents, saving time and money and paper. A number 
of the key managers were not so keen. I personally remember spending a lot of time with our finance director to 
persuade him of the benefits. Eventually, he agreed that it was the right thing to do and would not stand in the way 
of progress. 

In fact, when we went live, there was a lot of enthusiasm for the new system. All of the most active users found the 
system much better. However, after a while, we noticed the usage statistics were falling off. There was not as much 
activity on the system as there used to be. 

On further investigation, it turned out that the finance director was continuing to use the original paper-based filing 
system. He was also asking his team to print documents out for him. In turn, his team was starting to go back to the 
paper-based system too, as the finance director was annotating his notes on the paper copies. When I spoke with him 
again, he said that he would always want a current file in his office. As an interim step, though, we suggested that 
he archive the older files into the basement as had been our original plan. These files were already scanned into the 
system. This turned out to be the tipping point. 

Lessons learnt 

The problem wasn't so much that the finance director didn't want to use the new system. It was more the case that 
every time he needed to use it, he had to ask someone to show him how. And he had got tired of doing this - hence 
his reversion to the paper copies. By archiving the old files to the basement, he was now forced to use the system 
from time to time. And this was enough for him to get used to it. Once he had got enough confidence in using it, 
he used it more and more. Within 6 months, all the files had been moved to the basement. Our lesson learnt was 
basically to make the change irreversible. 
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5 Risk Management - 5 things to 
know 

5.1 The basic calculation - Problems vs. Risks? 

Organizations are forever concerned about the future, and effective managers should be looking ahead 
to see what opportunities exist and also what potential threats might arise. It is worth mentioning at 
this point that in the MoR standard from the OGC for the Management of Risk, risks can be either 
potential opportunities or threats. 

Nothing is certain about the future, so how do you decide which risks are worth addressing and which 
ones aren't? How do you get to a point where the organization is does something about them beyond 
just fretting? 

It is important to have a common way of assessing the relative importance of risks. The important 
questions that we need to ask are: 

1. What could go wrong (in general)? 

2. What could go wrong (in particular)? 

3. What can we do to reduce the chances of that happening? 

4. And since we can t be certain of stopping every unfortunate outcome, what can we do to 
minimise the impact were it to go wrong? 

So traditional risk management looks at four aspects: 

1. What are the general areas of vulnerability? 

2. What are the specific potential problems? 

3. What are the likely causes of these potential problems and what actions can we take to 
reduce the probability of them occurring? 

4. What actions can we take to mitigate the impact if our preventive actions fail? 

5.2 The Risk Register 

An obvious outcome of having a common process for looking at risks, is that a number of risks arise 
from a number of different potential problems. This list of risks is known as the risk register. Having 
it in one place allows the management team to assess the most important project risks and to agree 
collectively what is going to be done about them. The risk register typically has the following columns; 
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1. The general area of vulnerability (this can be the project as a whole, with each project 
having its own sub-register 

2. The owner of the risk. Often there is an incorrect assumption that the Project or Programme 
Manager is the Risk Owner for all risks. Risks should be "owned" at a level where there is 
sufficient authority to manage the risk meaning that some risks can be delegated and some 
need to be escalated. 

3. The probability of this risk happening - this can either be given as high, medium or low or 
alternatively a score out of 10, where a risk of certain probability is 10 

4. The impact on the project if this risk came to pass - again, this can either be given as high, 
medium or low or alternatively a score out of 10, wherea score of 10 means it has a critical 
impact 

5. Actions to reduce the probability of the risk happening and mitigate the impact of the risk 
happening (shown in column 8, 'risk management.' 

An example of a typical risk register is shown below 4 : 



Courtesy SofTools Ltd 
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Figure 3 

If you are overseeing a number of projects, beware of project managers using the risk register to avoid 
responsibility. Their risk register is closer to a list of everything that might go wrong on the project 
including things they are responsible for. The inference is that if they highlight them and the risk turns 
to reality, they are absolved from responsibility. Clearly this is not the case! 

Good project managers recognize that it is impossible to address all risks and to have an absolutely 100% 
confidence that everything will go according to plan. Their risk registers only contain the most serious 
risks to the project with focus on say the top five or ten. When these risks are managed, they fall out of 
the top 10. New, more serious risks then take their place. 

This technique works well for small and simple projects, but traditional techniques quickly get out of 
their depth when the projects get larger and more complex. A more sophisticated method is needed. 

5.3 Assumption based risk analysis 

It is a fact that many large, complex projects and programmes fail to meet their planned objectives - 
either failing to deliver what was promised, sliding the timeframes or exceeding the budget - or all 
three! Most organisations are undertaking one or more aggressive, "must do" programmes at any point 
in time. These may fundamentally change the way the company conducts its business and failure to meet 
objectives on time may have a catastrophic impact on business. 
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Many different risk management processes are used to improve delivery performance. These may range 
from very informal approaches, where the lack of process means that it ultimately has little impact, to 
formal documented processes, which deliver varying degrees of benefit. Very often these "traditional" risk 
management approaches are sound in theory but disappointing in practice. Some of the reasons include: 

A tendency to focus on todays issues rather than tomorrows risks 
The creation of generic risk statements that are too general to be useful 
An over-analysis using unsubstantiated numerical data 
An under- analysis using misleading High/Medium/Low type scales 
Inappropriate prioritisation so you "cant see the wood from the trees" 
Inability to get anyone to actually do anything about the risks! 

Assumption Based Communication Dynamics (ABCD) 5 is a highly effective risk management process 
that captures the collective knowledge and viewpoints from stakeholders on the project. It turns traditional 
risk management on its head by focusing on what is assumed to be working rather than what might 
go wrong. From the list of assumptions that a project is relying on, the focus can then be on why these 
assumptions might not hold true. The confidence level that an assumption is true is, of course, exactly 
the opposite of a risk. This is a really important point and is best illustrated with an example. Supposing 
we think the risk of some key equipment not being delivered on time is 20%. Rather than take the glass 
half empty approach, we could take the glass half full approach. In other words, we could state that we 
are 80% confident that the equipment will arrive on time. Or to put it a different way, we believe that 
the assumption that the equipment will be delivered on time is 80% true. 

At the most basic level ABCD works because it is an intuitive process that takes a positive view of the 
project (i.e. what assumptions are you relying on to achieve your objectives) rather than a negative one 
(i.e. what are you expecting to go wrong - your risks). By dramatically improving the communication of 
key assumptions, risks are avoided or managed proactively and project objectives are delivered on time. 

Other benefits of ABCD include the fact that it: 

• Naturally forces people to look to the future (i.e. their assumptions) and therefore ensures 
true risk management 

• Captures specific root-causes of risks (i.e. the assumptions) 

• Uses a positive outlook and encourages project members to surface more assumptions (and 
hence more risks) 

• Uses meaningful analysis that provides true insight and accurate prioritisation 



5 A fuller description of Assumption based risk management, QBC and Monte Carlo analysis is given in 
"FastTrack Risk Managment," by Keith Baxter 
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• Provides clear prioritisation and escalation from project through programmes to enterprise 
levels 

• Ensures follow through on actions via simple but effective roles and governance structures 

Assumption based risk management requires some changes in how risks are assessed. We look at: 

1. the stability of the assumption (equivalent to Probability in traditional risk management) 

2. the sensitivity of the project to the assumption (equivalent to Impact in traditional risk 
management) 

Once we have clear objectives and plans, programme and project managers must ultimately control two 
fundamental factors if they are to successfully deliver their objectives 

1. The assumptions that underpin the business plan must be clearly identified and 
communicated 

2. The assumptions made by the individuals in the implementation of the programme must be 
made explicit, rated and communicated. 
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Therefore the capture, analysis and communication of assumptions are critical to the success of the project 
or programme, and this forms the basis of the ABCD process. At the core of ABCD is the analysis of 
the assumptions. This process uses structured techniques to analyse project plans and identify the most 
sensitive assumptions that are potentially unstable, and therefore the source of greatest risk. Assumptions 
are rated for Sensitivity and Stability on an ABCD scale; where A is always "good" and D is always "bad". 
This provides a meaningful assessment on each assumption (i.e. there is no "medium!) This also guides 
the mitigation plans by indicating how best to attack the risk (i.e. stabilise the underlying assumption 
or de-sensitise the project to the effects of the assumption). 
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Figure 4 



5.4 A smart way of visualizing risk profiles 

The traditional approach of looking at the probability and impact of a risk (or the stability and sensitivity 
of an assumption) misses one additional dimension - that of urgency. Usually organizations look for the 
biggest risk and put it top of the priority list. Supposing, though, that the biggest risk was expected to 
take 12 months to mitigate. Focusing on this might mean that a more urgent risk is ignored because it 
is not at the top of the risk register. This problem is often compounded, because typically when a project 
starts, little consideration has been given to the correct sequencing of risk management activities and 
the overall risk plan. 
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A good way to show these three dimensions is the risk bubble diagram. Here, each risk is represented by 
an individual circle or bubble on the chart. The height of the risk off the ground,' represents the impact 
of the risk if it were to be realized. High is good. The lower impact risks are shown in green. The higher 
impact risks are shown in red and are nearer to the ground.' The way to look at this chart is to recognize 
that unmanaged projects will have risks that "cluster" around the origin. Bubble diagrams are particularly 
useful for showing trends in managing risks. The example below on the left shows a project not under 
control. Over time, the risk profile should move towards the situation on the right, i.e. a project that is 
being properly managed. 
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Figure 5 

The second aspect of the risk that this diagram shows is how well it is under control (this is represented 
by the diameter of the bubble). In other words, do we have plans in place to control it? So a risk is 
controllable if risk plans are in place and there is confidence that they will deliver the intended risk 
mitigation. A risk is not controllable if there is no plan in place or even if there is, that the plan will not 
significantly reduce it. The larger the diameter of the risk bubble, the less it is being managed. 

And so on to the third aspect, the urgency. The x-axis shows the timeline of the project, where the origin 
of the graph represents the critical objective of the project being met. The x-axis represents how much 
time is in hand to manage the risk. So the less urgent the risk, the further away the risk bubble. 

So, referring to figure 5 above, the left hand diagram shows a lot of large red risks close to the origin 
of the chart which means that there is a imminent high probability of severe impact risks with no plan 
to manage them. The right hand diagram illustrates a more manageable project. Whilst there are some 
red risks, these are some way off in the future and there is a chance to make them more manageable. 
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In terms of explaining the chart to senior managers, you want as few risks (i.e. bubbles) as possible, those 
that you have as high off the ground as possible (i.e. lowest impact), as far away to the right as possible 
(i.e. not yet urgent) and properly managed (i.e. with a small diameter). 

5.5 Quality based costing and Monte Carlo 

In practical terms, the most important question for a risk manager is: "What does the overall risk profile 
look like, and which are the risks I should manage to make the biggest difference?" 

The best technique for solving this problem in the world of projects is called Quality Based Costing 
(QBC) 6 . It quantifies the overall risk profile of a project and then lets you evaluate what impact the 
mitigation of a particular risk might be on the project. From this, you can then work out which are the 
most important risks to work on. 

It will then tell you: 

• What is the fastest the project can complete? 

• What is the most likely time it will take? 

• What is the lowest cost of the project? 

• And what is the most likely? 



Theory and examples of ABCD and QBC courtesy of De-Risk Ltd, www.de-risk.com ABCD risk management 
is a trademark of De-Risk Ltd 
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QBC accurately estimates this for any project. It works by acknowledging the inevitable quality variations 
in the project (time and cost) estimates and underpins all estimates with their underlying assumptions. 

QBC uses the concept of strategic cost "Bricks" in the project. Strategic cost means the cost in terms of 
lost benefits, time or money spent. The term Brick is simply used to avoid confusion with Work Packages, 
activities, tasks etc. The size of a Brick can vary considerably depending on the stage of project. The first 
step is to build the "Brick Wall" and when this is complete, all the Bricks together represent the total 
strategic cost structure of the project (with no estimates, at this stage). 

Brick Owners are allocated for each Brick based on the ability to estimate the specific Brick as accurately 
as possible. Brick Owners are then interviewed to "break-down" the Brick estimates into its components. 

This is done by asking structured questions that break the Brick down into: 

A = Absolute minimum 

A+B = Best guess/realistic estimate 

A+B+C = Contingency added 

A+B+C+D = Disaster scenario 

The assumptions that underpin the estimates are also captured using the ABCD Assumption Analysis 
process. The ratings of the assumptions must be consistent with the estimate breakdown. Discussion of 
these estimates often results in changes to the estimates and/or assumptions to make them more accurate. 

Each Brick then has two probability distributions built around the estimates - one for the "Contingency 
Scenario" and one for the "Disaster Scenario". 
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Monte Carlo simulations are then run to statistically add the Brick estimates together. A Monte Carlo 
simulation is basically where the different possible scenarios are run through the computer using the 
probabilities set up in the ABCD assessment. 7 The resulting probability distributions can be interpreted 
to make crucial decisions relating to budgeting, pricing or milestones e.g. 

• There is a "zero" probability of the project costing less than the "Base Cost" 

• The 50% confidence cost means that there is an 50-50 chance of the project costing less or 
more than this value 

• The 90% confidence cost is normally considered to be the "ideal" cost to budget (if this is 
considered affordable!) 

• To be meaningful, the project must be funded somewhere between the 50% and 90% costs 
The Add-up cost is simply the value that would have been reached through "traditional" 
estimating. The Add-up cost could appear anywhere on the graph but normally appears 
below the 50% point - it is therefore not surprising that traditional estimating is so far out! 
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Using QBC for competitive advantage 

QBC is sometimes used at the proposal stage of a project to provide the best possible information for 
competitive pricing and to give confidence that crucial milestones will be met. In non-competitive 
environments, it provides a scientific way of guaranteeing fair budgets and profit. In competitive situations, 
it allows suppliers to understand the level of risk that they are taking on and, if they choose, cut their 
price or timescales. It also allows for innovative pricing scenarios which can produce the most aggressive 
(fixed) price but with reduced risk to the supplier. 



7 The calculations shown are illustrations from AssureTM is a web-based tool from De-Risk, capturing ABCD 
data and generating reports (e.g. Risk Registers and "Bubble Diagrams") 
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Taking it one step further, it can help to bridge a discussion between vendors and their customers 
about risk. Vendors for example have traditionally been very wary of talking about risk. It makes their 
customers feel that things are expected to go wrong. However, with this kind of Monte Carlo analysis, 
you can do what if calculations to identify which tasks are the most valuable. Vendors can then state 
which tasks the client should take responsibility for and can clearly demonstrate the positive effect it 
will have on the project. It also avoids the vendor taking on risks they can do nothing about and those 
difficult discussions that often ensue. 
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Figure 8 

This analysis can also tell which areas of risk management to focus on. What you find in practice is that 
mitigating some activities to ensure that they are guaranteed to deliver earlier makes absolutely little 
or no difference in the cost' profile of the project. And small changes to others, or a simple project re- 
sequencing, makes a big difference. 

Why vendors are better at fixed price projects 

Contrary to popular belief, vendors are generatlly better at managing Fixed Price projects whereas end 
users typically fail. There are three primary reasons which end users might wish to consider. 

1. Risk Management -vendors use risk mgmt to establish the level of Contingency, then they 
add profit margin on top. 

2. Change Control - vendors will keep a keen eye on things that are outside the contractual 
scope and will apply Change Control to ensure every project is profitable. 

3. Resource Availability - vendors will allocate sufficient and dedicated (i.e. 100%) resources to 
a project and when necessary will add resources to ensure they meet deadlines. Whereas in 
end-user organisations, resources are often shared across projects and project prioritisation 
can affect resource allocation. 
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6.1 The special role that IT managers play in business change 

Business change projects with IT at their heart have been around for many years. So, assuming that 
experiences are shared and lessons learnt, why do so many of them go wrong? From all our work with 
CIO's, two things at least seem clear. Firstly, all change programmes depend on people and emotions 
can run high. Secondly, there are programme management considerations to take into account, and not 
all of them will be known at the beginning. It needs extensive programme management experience to 
take on the changes and still keep the project on track. 

Most business change in an organization concerns new products, services and ways of doing business 
(processes). The IT department can therefore expect to be at the heart of change in any organization - 
helping to change the systems that support product design, manufacture, pricing, sales and marketing, 
as well as all other internal processes. 

Senior IT managers are often involved in major change initiatives. However, they are rarely the primary 
business sponsor. This sometimes seems unfair, as they often have immense experience in delivering major 
programmes. But here is the catch. As soon as a senior IT manager starts taking over a change initiative, 
it can stop being seen as a business change programme and become an IT project. The reality is that IT 
managers have an extremely difficult task to perform in business change. There are two primary tasks: 

1. To monitor progress in the background and apply their business programme experience to 
ensure the success of the change project 

2. To coach and guide the business to lead their own change 

The role of IT executives is in some ways more difficult than that of the change leader. Using experience 
from previous initiatives, their role is to coach and advise the business change leader of the key areas to 
focus on to make the business change programme successful. 

6.2 Success guidelines for business change 

When it comes to lessons learnt, the good news is that there are many. In the table below, you will find 
our top guidelines put together from several hundred IT managers who have attended our courses. 

The table / model below captures these lessons learnt using a model of four change phases, namely: 

Phase 1 - Making the case for change 

Phase 2 - Starting out 

Phase 3 - On the change journey 

Phase 4 - Completing the change program 
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Phase 1 - Making the case for change 

* Look for opportunities for change 

* Make sure the organization is ready to take on the challenge 

* Be clear on what needs to be delivered for the benefits to be 
realized. Understand which components / products lead to which 
benefits so that there is a clear line of sight/ 

* And make sure the business case really stacks up -just because 
the numbers are large and positive doesn't make them right You 
should always get to the heart of the business case and 
understand what needs to be delivered for the benefits to be 
realized 



Phase 2 Starting out on the change journey 

* Link the vision to the benefits 

* Prepare some of the detail ahead of time, for example, enterprise 
and systems architecture 

* Work through the plan and let the users complete the detail so 
they feel empowered 

* Help the business communicate the vision, but remember, this is 
their job 



Phase 3 - On the change journey 

* Make sure you are ready to endure the difficult times 

* Keep an eye on the benefits through the deli very journey 

* Keep programme managing 

* Keep the stakeholders engaged 

* Keep communicating 

* Keep delivering quick wins 

* Keep celebrating success 



Phase 4* As the programme nears its end 

* Don't give up 

* Make sure you prepare for operational mode 

* Solve operational problemsquickly 

* Realize the benefits- measure and review them 



Table 6 
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It also makes sense to have a view of the key lessons learnt from the business point of view. There is no 
better reference that those of John Kotter, Professor of Leadership at Harvard Business School (so he 
ought to know!) in his two books, Leading Change 8 and the Art of Change 9 . Both books are excellent, 
but the second one, is particularly good with some excellent case stories, illustrating change leadership. 
Many of his change leadership lessons are included in our list compiled in the previous table. 

Leadership and vision are vital ingredients in successful change projects - both from the programme 
team and the senior executives in the organization. It needs to be consistent. It is not acceptable for 
senior management to join the kick-off meeting with promises of commitment and statements about 
how important the project is, only for them to be never heard of again. Managers need to be constant 
supporters of change and they need to be accountable for its success. Organizations that have a good 
track record of executive support for change in the past have been shown to consistently have success 
in the future. 

The key lesson in phase two, "Helping the business communicate the vision," needs a particular mention. 
A proper shared vision is a vital part of a change project. General high level statements of intent can often 
appear nebulous and valueless. In the context of business, vision is about describing what the end will 
look like. It can be described in any way that works. It can be a rousing statement of future achievement, 
a video, an animation or anything that appeals to the mood of the moment. Employees need to have a 
clear understanding of the vision - it needs to be consistent with the company's strategy, which in turn 
needs to be consistent with the day to day activities. 

6.3 The emotional side of (business) change (DREC) 

Now for something completely different - brain science. You may have seen some of the images of the 
brain where scientists trace the energy coursing through it. Experiments have been done on patients put 
in unfamiliar situations. In these situations, these energy traces show that the pre-frontal cortex at the 
front of the brain lights up. The pre-frontal cortex is equivalent to brain RAM. The pre-frontal cortex 
is agile, but can only deal with a handful of concepts at one time. When it bumps against its limits, it 
generates a palpable sense of discomfort, leading to fatigue and sometimes anger. In fact, the pre-frontal 
cortex is linked to our primitive emotional centre. 

Given the choice, our brains prefer to use the lower energy basal ganglia (brain hard drive) - this controls 
habit-based behaviour. What the science seems to show, is that the brain has a reward mechanism when 
we gain insights into doing new things, in other words, transferring the workload from one of fear in 
the pre-frontal cortex, to one of mastery in the basal ganglia. 



'Leading change John Kotter, Harvard Business Press 
'The art of change John Kotter, Harvard Business Press 
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So why is this important in business change leadership. Well, it supports the theory that business change 
can be an emotional journey, causing extremes of behaviour in those who are affected. It also suggests, 
given the reward mechanism for insights, that those who are affected by the change need to be empowered 
to work through the implications of new change. In other words, the role of the change leader is to 
provide the framework so that the users can master their own destiny, coming to terms with new change. 

There is a model that you may have seen before, called the DREC curve. It explains the different phases 
of emotion that people go through when confronting major change. The acronym stands for: 

1. Denial 

2. Resistance 

3. Exploration 

4. Commitment 
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The DREC curve 
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Figure 9 



Phase one is our "Ordinary world" in other words, the world we are living in today. Suddenly, a new 
change programme is approved and the journey begins. If those who are directly affected by the change 
are not ready or prepared, a number of emotions will come to the surface. The first of these emotions 
is denial. Users tell themselves "I can't believe they will really do this." Then as things progress, denial 
may turn to anger. "This is absolutely the wrong thing for us to be doing. It could severely damage our 
business." 

Emotions may build, as the project moves on often with a bargaining phase. "Why don't we start with 
the other region first?" Finally, they may move on to pessimism and despair, asking themselves, "I don't 
see how this will ever work." 

We come to the bottom of the curve. If the project is going to fail, chances are, it will fail here. If we can 
get past this stage and move to phase 3, then we have a chance of being successful. The project starts to 
deliver some early results and those affected may get involved with verifying them (remember what we 
said previously about delivering step by step). Users may even recognize some value in what is being 
done. This cautious optimism builds, through hopeful realism and even acceptance. 
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As the project nears completion, there is an informed optimism. Those who have been involved through 
the change journey are now emerging on the other side. The theory of brain science says they will feel 
a sense of great satisfaction and achievement. 

To summarize 

• Changing the way we do things will often bring about an emotional reaction 

• Large business change may bring about large emotional reactions 

• As change leaders, we need to recognize the emotional journey, and help others to work 
through it 

When you are embarking on a new change programme, think about how it would play out as a script. 
What would be the denials and the resistance to the programme? What sorts of obstacles would you 
need to overcome? What would the new ordinary world' look like? Thinking through a change journey 
as a film narrative can often be a good way to identify and hopefully address change issues early. 

6.4 The importance of a good team 

Given what we have said in the previous section about the emotional effects of business change, working 
on business change programmes isn't for everyone. And as an IT leader, it is your job to assign the right 
people to the right change programmes. There will often be difficult times to endure and it is all the more 
important, therefore, to have a good group of people around you who can work well in such situations. 
So how do you go about finding these people? The model shown in the matrix below may help you: 
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This model is a classic 'Boston matrix,' a two by two matrix, with positivity of outlook on the x-axis and 
level of proactivity on the y-axis. So, on the one hand, you need to consider whether someone has a 
positive or a negative outlook. And secondly, you will have those who are proactive and those who are 
reactive. You can see from the Boston matrix above that we end up with four personality types. 



Jane's story 
Background 

We obtained approval for a large company-wide change programme. I had only been in my post for a short time and 
had been spending a disproportionate amount of my time looking at the budget numbers. The company had grown 
quickly through acquisition and our region comprised five different companies which had been acquired at different 
times over the previous few years. Two of them occupied the building where my office was situated - an office which 
was in great need of refurbishment. 

What happened 

One of my first tasks was to set the programme budget. The finance organisation had assigned someone from their 
department to work with me full-time. The first time that I had occasion to speak to her, I asked if we could meet up. 
Her office was 40 yards down the corridor through some double doors. Unfortunately, my security pass would not let 
me through these double doors. I looked through the small window in the door to the other side. The offices there 
were very smart, with a plush blue carpet throughout, emphasizing the stark contrast to my side. 

I called the finance manager to tell her I couldn't get through. She said that the doors were permanently locked. It 
was a hangover from when the companies first merged. To get to her office I had to leave my side of the building, 
walk round to the other reception, sign in and then be escorted to her office. It seemed everyone had just got used to 
this. But from my point of view it represented a great fracture in the company and an obstacle preventing everyone 
from working effectively together. With the agreement of the managing director, we managed to get the doors 
opened. It became much easier for me to meet with my finance representative, taking care to wipe my feet first. 

Lessons learnt 

This incident gave me a real insight into some of rifts that existed in the company. If our change project was to be 
successful, we needed team members not only from all departments but also from different acquired companies and 
all levels of seniority. So that is what we did and the change team performed miracles. 

Change leaders (High energy and positive) - Clearly the people you will want on your team are those 
with a positive outlook and who are proactive, in other words, fast moving. Surely, these are the people 
you recruited yourself! These are your champions, your change leaders, those you can rely on to inspire 
others and to make things happen. But as you look around you, you may find that not everyone fits into 
this category. Keep them informed of everything that is going on. Canvass their input and adjust your 
plans accordingly. Seek to provide them with more responsibility, not forgetting to transfer the authority 
needed to carry it out. 

Spectators (low energy and positive) - these are your followers. They will do whatever the progamme 
leaders asks of them. Keep them motivated and engaged in the programme. Give them opportunities 
to take on new tasks. Spectators have a positive outlook, but typically do not have the same level of 
inspiration and proactive energy as your proactive change leaders. 
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Victims (Low energy and negative) -Victims often have other things on their mind. They are the ones that 
can see all the things that could go wrong, but do absolutely nothing about it. It seems logical to assume 
that they didn't behave like this when they were interviewed for the job. So presumably something has 
happened that has caused them to move from positive to negative behaviour. Take time to understand 
their issues. If you are thinking of taking away their responsibilities, speak to them first. Get them to 
understand why you feel they are not contributing as they should. Keep them informed, even if keeping 
them motivated is not a good use of your energy. 

Troublemakers (High energy and negative) - Troublemakers pose the greatest threat to your project. 
They are often well connected and can spread rumours and gossip that may undermine what you are 
setting out to achieve, or they may diminish the value of what you have achieved. What makes things more 
difficult is that they are usually very clever and fast moving. And what makes them doubly difficult is that 
it is not always easy to recognize them. They do not wear a bandana or balaclava. They will not openly 
oppose the change, but they will be working in the background, being helpful, but in an unhelpful sort 
of way. If you are the change leader, always be looking out for these people. Spend time with them and 
try to turn them around. They are unlikely to be irrational - just obstructive. If possible, involve them in 
part of the project with high kudos. If you can turn them round, it will do untold good to your project. 

With reference to Jane's story on the previous page, on her side of the office people were behaving as 
Victims and on the Finance manager's side they were behaving like Spectators until Jane took proactive 
steps to break down the barriers 

If the plan for the future is radical, the current team may not possess the skills or desire to make it 
happen. If so, think about changing the team members. This is easier said than done, because you will 
not only have to recruit the right people, you may also need to move others out of the way. It may have 
a knock-on effect on the morale of the remaining team members. When making team changes, be bold 
and make them early. 
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7 Outline of the top project 
frameworks 

For many years, the IT profession was concerned about the high rate of project failure. It seemed that 
many of the same mistakes were being made again and again. To try and stem the tide of project failure, 
a number of best practice frameworks were put in place. Two are them, namely PRINCE2 from the 
OGC and PMP from the Project Management Institute are described in the next two sections. Now, let 
us be clear here. Just because you are using a best practice framework does not mean that you project 
will be successful. Many of the reasons for project failure cannot be described in a process manual, any 
more than following a recipe in a cookery book will ensure your cakes will come out perfectly! There 
will still be projects that fail. Nonetheless, following any methodology is better than not following any 
methodology. Why? Because a methodology allows you to repeat success rather than to risk failure. 



7.1 



International standards 



For any manager to be successful in managing a project themselves, or overseeing a group of projects, 
clearly they need to have a good method in place. 



There have been several attempts to develop project management standards, such as: 
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PRINCE2 - PRojects IN Controlled Environments. 

Association for Project Management - Body of Knowledge 

Capability Maturity Model - from the Software Engineering Institute . 

The ISO standards ISO 9000 - a family of standards for quality management systems 

GAPPS, Global Alliance for Project Performance Standards - an open source standard 

describing competencies for project and programme managers 

The most common methods are PRINCE 2 10 and the PMI 11 method. To find out more, the following 
two references will help - "PRINCE2 - What you need to know" and "the Project Management Book of 
Knowledge" and I commend both of them for those who are interested in learning more about these 
methods. In addition, for anyone aspiring to manage or already managing projects, it makes eminent 
sense to become qualified and there are many companies world-wide who can provide the accreditations 
necessary. 

7.2 PRINCE2 

Published by the UK Government agency CCTA in 1989, Projects in Controlled Environments (PRINCE) 
became the UK standard for all government information systems projects. It was upgraded in 1992 to 
become the PRINCE2 standard we know today. It is a process-based project management method as 
opposed to a more adaptive method such as found in agile development type projects. It has been enhanced 
over time, with more recent updates in particular making it simpler to use and better integration with 
other OGC methods (e.g. ITIL, P30, P3M3 , MSP, M_o_R etc.). 

PRINCE2 is the framework most commonly used in the UK. It provides proven best practice, a common 
vocabulary and can be used on any type of project. PRINCE2 is based on seven key principles. 

7.3 Project Management Institute 

The Project Management Institute, Inc. (PMI) standards and guidelines are developed through a voluntary 
consensus standards development process. PMI administers the process and establishes rules to promote 
fairness in the development of consensus. The standards and guidelines are contained in the Project 
Management Book of Knowledge (PMBOK), a book that we would also recommend to anyone interested 
in project management as a recognized standard for project managers world-wide. 



10 'PRINCE2 - What you need to know' © Crown Copyright 2009. Reproduced under licence from the Cabinet 
Office. 

1 1 'Project Management Book of Knowledge' from the Project Management Institute 
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The PMI framework consists of five Project Management Process Groups, each of which is required 
for every project. The Process Groups have clear dependencies and are typically performed in the same 
sequence. They are not separate project phases. Projects, particularly IT projects, are of course normally 
divided into phases or sub-projects, such as feasibility study, concept development, design, prototype, 
build and test. All of the Process Groups would normally be repeated for each phase. 

7.4 Agile Development 

Agile methods are sometimes characterized as being at the opposite end of the spectrum from plan- 
driven or disciplined methods such as the PRINCE2 or PMI frameworks. 12 The key theme is that they 
are versatile, adapting to the speed of changing business requirements, or practically speaking, allowing 
business users to evolve their ideas through the development process. "We don't know exactly what we 
want, but we can tell you what we don't want, and we will be able to better explain it if you put something 
in front of us." Agile methods have much in common with the Rapid Application Development techniques 
from the 1980/90s. 

An adaptive team cannot report exactly what tasks are being done next week, but only which features 
are planned for next month. When asked about a release six months from now, an adaptive team might 
be able to report only the mission statement for the release or a statement of expected value vs. cost. 13 

Agile Manifesto 

In February 2001, 17 software developers published the Manifesto for Agile Software Development. Twelve 
principles underlie the Agile Manifesto, including: 

1. Customer satisfaction by rapid delivery of useful software 

2. Welcome changing requirements, even late in development 

3. Working software is delivered frequently (weeks rather than months) 

4. Working software is the principal measure of progress 

5. Sustainable development, able to maintain a constant pace 

6. Close, daily co-operation between business people and developers 

7. Face-to-face conversation is the best form of communication (co-location) 

8. Projects are built around motivated individuals, who should be trusted 

9. Continuous attention to technical excellence and good design 



12 In fact, Agile and PRINCE2 are not mutually exclusive. It is possible to use the PRINCE2 governance 
framework and to treat each SPRINT iteration as a Work Package. 

13 We are grateful to VersionOne for their expertise and their summary of agile methods which is outlined here. 
More information can be found on their website www.versionone.com 
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10. Simplicity 

11. Self-organizing teams 

12. Regular adaptation to changing circumstances 

Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report 
exactly what features and tasks are planned for the entire length of the development process. Predictive 
teams have difficulty changing direction. The plan is typically optimized for the original destination and 
changing direction can require completed work to be started over. 

Characteristics 

There are many specific agile development methods. Most promote development, teamwork, collaboration, 
and process adaptability throughout the life-cycle of the project. The agile method breaks tasks into small 
increments with minimal planning and do not directly involve long-term planning. Iterations are typically 
last from one to four weeks. Each iteration involves a team working through a full software development 
cycle, including planning, requirements analysis , design , coding , unit testing , and acceptance testing when 
a working product is demonstrated to stakeholders. This minimizes overall risk and allows the project 
to adapt to changes quickly. Multiple iterations are usually required to release a product or new features. 
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For agile methods to work, stakeholders need to be more closely involved in the development, more 
tolerant of the software not doing what is required first time out, but welcoming of the fact that not 
everything needs to be documented in detail. The teams are often highly collaborative and usually 
quite egalitarian. It is very helpful for the agile teams to be located in the same office to maximize 
communication. Although collaborative, the agile team needs a customer representative who is fully 
committed to the project. One thing we have learnt over and over again is that if too many project 
members are assigned to work part time on the project, the project will usually fail. 

Well-known agile software development methods include: 

1. Agile Modelling 

2. Agile Unified Process (AUP) 

3. Dynamic Systems Development Method (DSDM) 

4. Essential Unified Process (EssUP) 

5. Exia Process (ExP) 

6. Extreme Programming (XP) 

7. Feature Driven Development (FDD) 

8. Open Unified Process (OpenUP) 

9. Scrum 

10. Crystal Clear 

1 1 . Velocity tracking 

Some of the main ones are summarized as follows: 

Scrum 

In Scrum, the "Product Owner" works closely with the team to identify and prioritize system functionality 
in form of a "Product Backlog". The Product Backlog consists of features, bug fixes, non-functional 
requirements, etc. - whatever needs to be done in order to successfully deliver a working software system. 
With priorities driven by the Product Owner, cross-functional teams aim to deliver "potentially shippable 
increments" of software during successive Sprints, typically lasting 30 days. Once a Sprint's Product 
Backlog is committed, no additional functionality can be added to the Sprint except by the team. Once 
a Sprint has been delivered, the Product Backlog is analyzed and reprioritized. Scrum has been proven 
to scale to multiple teams across very large organizations (800+ people). 
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Extreme Programming (XP) 

XP promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, 
and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks. 
In XP, the "Customer" works very closely with the development team to define and prioritize granular 
units of functionality referred to as "User Stories". The development team estimates, plans, and delivers 
the highest priority user stories in the form of working, tested software on an iteration by iteration basis. 
In order to maximize productivity, the practices provide a supportive, lightweight framework to guide 
a team and ensure high-quality software. 

Crystal 

The Crystal methodology is one of the most lightweight, adaptable approaches to software development. 
Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, 
etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and 
project priorities. Like other agile methodologies, Crystal promotes early, frequent delivery of working 
software, high user involvement, adaptability, and the removal of bureaucracy or distractions. Alistair 
Cockburn , the originator of Crystal, has released a book, "Crystal Clear: A Human-Powered Methodology 
for Small Teams". 

Dynamic Systems Development Method (DSDM) 

In 1 994 the DSDM Consortium was created and convened in 1 994 with the goal of devising and promoting 
a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has 
evolved and matured. DSDM specifically calls out "fitness for business purpose" as the primary criteria 
for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed 
in 20% of the time. 

Requirements are baselined at a high level early in the project. Rework is built into the process, and 
all development changes must be reversible. Requirements are planned and delivered in short, fixed- 
length time-boxes, also referred to as iterations. Requirements for DSDM projects are prioritized using 
MoSCoW Rules: 

M - Must have requirements 

S - Should have if at all possible 

C - Could have but not critical 

W - Won t have this time, but potentially later 

The DSDM project framework is independent but can be implemented in conjunction with, other iterative 
methodologies such as Extreme Programming and the Rational Unified Process. 
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Lean Software Development 

Lean Software Development is an iterative methodology originally developed by Mary and Tom 
Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise 
movement, and the practices of companies like Toyota. Lean Software Development focuses the team 
on delivering Value to the customer, and on the efficiency of the "Value Stream," the mechanisms that 
deliver that Value. The main principles of Lean include: 

1. Eliminating Waste 

2. Amplifying Learning 

3. Deciding as Late as Possible 

4. Delivering as Fast as Possible 

5. Empowering the Team 

6. Building in Integrity 

7. Seeing the Whole 
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Lean eliminates waste through such practices as selecting only the truly valuable features for a system, 
prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency 
of development workflow, and relies on rapid and reliable feedback between programmers and customers. 
Lean uses the idea of work product being "pulled" via customer request. It focuses decision-making 
authority and ability on individuals and small teams, since research shows this to be faster and more 
efficient than hierarchical flow of control. It concentrates on concurrent work and the fewest possible 
intra-team workflow dependencies. 
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8 In conclusion 

8.1 Take time to reflect 

This book summarizes the lessons we have learnt in managing IT projects and programmes and in 
business change leadership from other IT managers. I have tried to include the most valuable lessons 
from my own project management experience and that of delegates from our courses. I hope you found 
them valuable and will continue to add your lessons learnt to this list. There is nothing more valuable 
than a checklist for when you are running your own major program, or overseeing the projects of others. 

8.2 Staying ahead 

The fact that you have taken time to read and think hard about the ideas presented suggests that you are 
already keeping up to date with the latest thinking in our field. IT is fast changing and new technologies 
provide us with new and interesting opportunities. Many of the management disciplines we need, 
fortunately, do not change as fast, but it still helps to keep up to date. My most useful references are the 
Harvard Business Review, CIO Magazine and the Economist. I am also an avid reader of business books. 
You may also be interested in the other three books in our series: 

• IT Management - Managing people 

• IT Management - IT strategy and technology innovation 

• IT Management - IT business and operational excellence 

If you would like some advice on any of the topics, please feel free to email me at david.mckean@ 
itleaders.co.uk. 

We are also interested in your own experience and project lessons learnt, so feel free to forward me your 
stories. We also welcome your feedback on this book and your suggestions for how we can continue to 
improve it. 

Good luck! 

David McKean 
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